Web-Based Interaction With a Local System

ABSTRACT

Systems, methods, and computer program products for facilitating web-based interaction with a local system are disclosed. Such systems, methods, and computer program products provide an approach that allows a web client within in a web browser environment to access local hardware and local software—via a web server contained in the local system—in a local computer system. In response to a user input, the web client directs local hardware and local software to perform actions (e.g., writing files and taking pictures). Information related to such actions is returned to the web client via the local web server. The local computer system may be remotely located from the web client and such returned information may be stored and/or executed at a remote site (e.g., cloud database). Security layers may be provided to authenticate the user as well as user permissions for accessing the local computer system.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to remote access interfaces andmore particularly to systems, methods, and computer program products forfacilitating web-based interaction with a local computer system.

BACKGROUND

Developers typically design Internet websites to be platform agnostic.This is done using web-based programming models, such as HTML, HTML5,CSS, representational state transfer web services, JavaScript, and thelike. Such agnostic platform design allows all website visitors (i.e.,users) to have a consistent experience regardless of the web browserapplication, computer operating system, and hardware platform employedby such various users. Similarly, web-based applications (e.g., Flashgames, video players, audio players, mortgage calculators, etc.) aredesigned such that the programming model of the web-based applicationhas a consistent experience for all users across all computingplatforms. Alternatively, the developer may choose to limit thecomputing platform(s) the web-based application may be accessed from(e.g., by enforcing a “smartphones only” or a “tablet computers only”policy).

Generally, web browsers and web browser environments provide anisolated, consistent rendering and application programming interface(API) for web-based applications that does not provide access to thecomputing device's underlying and/or local system device drivers,services, and/or operating system APIs. Rather, web-based programmingmodels provide an isolated environment in which web-based applicationcan provide a defined set of functionality across a variety of computingdevice platforms. This is because if these web-based applications'software code were freely allowed to download and execute on the user'scomputing device, the software code could maliciously expose the memory,personal data, and/or operating system resources of the local computingdevice. Thus, in order to avoid compromising the user's computing device(or even remote computing devices in network communications with theuser's computing device) from unknown, untrusted, and/or untestedsoftware code, these web-based applications often run in an isolatedenvironment within the web browser environment.

Put another way, the isolated environment described above preventsweb-based applications from accessing or making use of any underlyingoperating system services (e.g., drivers, APIs, reading and writingfiles, controlling input devices, etc.). Such an isolated environment,implemented by the above-mentioned web-based programming models, allowsweb-based applications to operate with limited, tightly-controlledresources. Thus, network access and access to the host system andoperating system services are typically unavailable and/or prohibited.

SUMMARY

This summary is provided to introduce a selection of concepts. Theseconcepts are further described below in the Detailed Description. Thissummary is not intended to identify key features or essential featuresof the claimed subject matter, nor is this summary intended as an aid indetermining the scope of the claimed subject matter.

The present disclosure provides methods, systems, and computer programproducts that facilitate web-based interaction with a local computersystem. In an embodiment, a component detects a user input made within aweb-based application (i.e., client or client application). The clientis located within a web browser environment. The user input indicates auser-desired action at a local system, such as taking a picture using alocal system's camera. In an embodiment, the local system is remotelylocated from the user's computing device. In response to the user input,the client causes its local system interface component to transmit arequest signal—based upon the user input—to the local system. The clientreceives a response signal from the local system, which containsinformation related to a requested action specified by the user input.

In an embodiment, the user input initially requests an action to betaken on local hardware and local software. Data is then transferred toa web-based service and a component of the client determines whether theclient needs to contact a remote server. If communication with a remoteserver is required, a remote server interface component of the clientsends a signal—containing desired information—to the remote server.

In yet another embodiment, security layers may be provided when a moduledetermines whether the requested action—based upon the user input—is apermissible action. Such security layers (authorization process(es)) maybe implemented via a single step or multiple steps. Further, suchauthorization process(es) may be performed on a per-application basis,per-device basis, or “all-or-nothing” basis.

Further features and advantages of the present disclosure, as well asthe structure and operation of various aspects of the presentdisclosure, are described in detail below with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present disclosure will become moreapparent from the detailed description set forth below when taken inconjunction with the drawings in which like reference numbers indicateidentical or functionally similar elements.

FIG. 1 is a block diagram illustrating an interrelationship betweenexemplary components that facilitate web-based interaction with a localsystem, according to an embodiment of the present disclosure.

FIG. 2 is a flowchart illustrating an exemplary process for facilitatingweb-based interaction with a local system, according to an embodiment ofthe present disclosure.

FIG. 3 is a flowchart illustrating an exemplary process for facilitatingweb-based interaction with a local system, according to an embodiment ofthe present disclosure.

FIGS. 4A-B are flowcharts illustrating exemplary processes forfacilitating single-step and multi-step security methods, according toan embodiment of the present disclosure.

FIGS. 5A-B are flowcharts illustrating exemplary processes forfacilitating per-device-based and per-application-based securitymethods, according to an embodiment of the present disclosure.

FIG. 6 is a flowchart illustrating an exemplary process for facilitatingweb-based interaction with a local system, according to an embodiment ofthe present disclosure.

FIG. 7 is a block diagram of a computer system useful for implementingthe present disclosure.

FIG. 8 is a block diagram illustrating an interrelationship betweenexemplary components that facilitate web-based interaction with a localsystem, according to an embodiment of the present disclosure.

FIG. 9 is a block diagram illustrating an interrelationship betweenexemplary components that facilitate web-based interaction with a localsystem, according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

The present disclosure is directed to methods, systems, and computerprogram products for facilitating web-based interaction with a localcomputer system.

Referring to FIG. 1, a block diagram illustrating an interrelationshipbetween exemplary components that facilitate web-based interaction witha local system, according to various embodiments of the presentdisclosure, is shown. Configuration 100 depicts local system 104containing a local web server 107, local hardware 111, and localsoftware 112 accessed by a web client 102. Local web server 107communicates with local system interface 105, local hardware 111, andlocal software 112. Web client 102 contains software modules forcontrolling operations of remote sever interface 115 and local systeminterface 105. Remote server interface 115 communicates with remoteserver 114 and local system interface 105.

In various embodiments, the methods, systems, and computer programproducts of the present disclosure provide an isolated web-basedapplication, also referred to as web client 102, operating within a webbrowser environment 103 capable of accessing local system 104.Interaction is accomplished via a local system interface 105—locatedwithin web browser environment 103—that is located within web client 102in communication with local web server 107, which is located at andoperated by local system 104. For the purposes of this disclosure,“local system” 104 is the computing device or devices that web client102 accesses.

In an embodiment, local system 104 preferably includes computing devicesequipped with local software 112 and/or local hardware 111 (e.g.,cameras; scanners; global positioning system (GPS) antennae; motors;heat, light, motion or other sensors; etc.). In an embodiment, localsystem 104 preferably includes computing devices capable of locallyreading and writing data (e.g., media player, audio/video player, etc.).In an embodiment, web client 102 communicates with remote server 114 tofacilitate a web-based service, as specified by user input 101 from user110 at a user interface screen of web client 102. In yet anotherembodiment, security layers are provided to authenticate user request(i.e., user input 101), thereby controlling access to local system 104.The authentication process limits access to local system 104 via localweb server 107.

In an embodiment, web client 102 operates within web browser environment103. In an embodiment, web browser environment 103 is a web browseroptimized for operating on a portable electronic device (e.g., mobilephone, slate, laptop, etc.). In an embodiment, web browser environment103 operates on a stationary electronic device (e.g., standalonecomputing device, enterprise computing device, workstation, etc.). Insuch an embodiment, web client 102 includes one or more local systeminterface 105 modules and remote server interface 115 modules. Thesemodules 105, 115 communicate with one or more local systems 104 andremote servers 114, respectively. Modules 105, 115 generate and sendsignals in response to directives from web client 102 and receivesignals from local systems 104 and remote servers 114, respectively.

In an embodiment, modules 105, 115 are portions of software codecontained within web client 102 for facilitating communication withtheir designated targets (i.e., local systems 104 and remote servers114). In an embodiment, local system interface 105 and remote serverinterface 115 are part of an APIs designed to allow web client 102,within web browser environment 103, to access specific local system 104services. In an embodiment, local system interface 105 module and remoteserver interface 115 module may be part of web client 102. In anembodiment, local system interface 105 contains selected portions of anAPI required to communicate with local system 104 and/or remote server114. That is, when a developer has designed web client 102 to interactwith only a portion of local system 104, it is unnecessary to implementall portions of software code to communicate with local system 104.

In an embodiment, web client 102 utilizes local system interface 105 tocommunicate with local system 104. Local system interface 105 generatesand transmits request signals 106 to local web server 107, located on,and operated by, local system 104. In an embodiment, local systeminterface 105 provides additional APIs that facilitate interaction withlocal system 104 without additional developer knowledge of the localsystem 104 configuration (e.g., HTML, HTML5, CSS, representational statetransfer web services, JavaScript, etc.).

In an embodiment, local web server 107 is a component of local system104 that allows access to local hardware 111 and local software 112 oflocal system 104. Local hardware 111 may include hardware capable ofbeing operated at least in part by a computing device. Local hardware111 may include internal and external input and output devices of localsystem 104 (e.g., cameras, scanners, global positioning system antennae,motors, sensors, etc.) In an embodiment, local hardware 111 may includedevice drivers and APIs associated with the above-listed devices. Localsoftware 112 may include all software capable of running on a computingdevice (e.g., operating system contained on local system 104 and itsservices, APIs, third-party application programs, other computingservices, etc.). In an embodiment, local software 112 includes adigital, modifiable calendar. In yet another embodiment, local software112 includes a service that facilitates reading and writing filescontained on local hardware 111.

In an embodiment, local web server 107 is a component of an operatingsystem executing on local system 104. In an embodiment, local web server107 may be a separate software program from the operating system,provided by the same and/or different developers of the operatingsystem. In an embodiment, local web server 107 accesses local hardware111 and local software 112 via application development models that havedirect knowledge of the operating system (e.g., C/C++, Win32, MFC, .NETFramework, APIs exposed through software development kits, etc.).

In an embodiment, local web server 107 is capable of returning responsesignals 109 to local system interface 105 of web client 102. That is,local web server 107 sends signals to local hardware 111 and localsoftware 112, which cause local hardware 111 and local software 112 toperform the desired action, as specified by user input 101. Localhardware 111 and local software 112 returns information—related to thedesired action—to local web server 107. Local web server 107 thengenerates response signals 109 containing information related to thedesired action, which was carried out by local hardware 111 and localsoftware 112. Response signal 109 is sent by local web server 107 tolocal system interface 105 located at web client 102 in web browserenvironment 103. These software modules allow APIs of web client 102 inweb browser environment 103 to access local system 104 and utilize thelocal system services of local hardware 111 and local software 112.

Referring to FIG. 2, a flowchart illustrating an exemplary process 200for facilitating web-based interaction with a local system, according toan embodiment of the present disclosure, is shown. In step 202, a userinput 101 is received at web client 102. In an embodiment, user input101 is from a user 110 indicating a desired action to initiate via thegraphical user interface (GUI) of web client 102. (As will beappreciated by those skilled in the relevant art(s) after reading thedescription herein, user input 101 may be communicated to web client 102by a computing device remotely located from web client 102.)

In step 204, web client 102 utilizes local system interface 105 tocommunicate with local system 104. That is, local system interface 105generates and transmits one or more request signals 106 to local webserver 107 located on local system 104.

Then, in step 206, local web server 107 returns one or more responsesignals 109 to local system interface 105 of web client 102. That is,local web server 107 causes local hardware 111 and/or local software 112to perform the desired action, as specified by input 101. Local hardware111 and local software 112 returns information—related to the desiredaction—to local web server 107. Local web server 107 then generatesresponse signals 109 containing information related to the desiredaction, which was carried out by local hardware 111 and local software112.

As will be appreciated by those skilled in the relevant art(s) afterreading the description herein, “user input 101” as described herein mayalso be a non-user initiated action. That is, for example, web client102 may be a GPS-enabled application (executing within web browserenvironment 103) with a timer that continuously queries to obtaincurrent GPS location via a remote (API) call to local system 104 (i.e.,local hardware 111).

As will be apparent to one skilled in the relevant art(s) after readingthe description herein, code implementing process 200 (and processes300-600 described below), that facilitates web-based interaction with alocal system may be part of a “standard” version of a web client 102application that ships from a developer or may be later added as part ofa update (or patch). Further, a web client 102 application utilizing anembodiment the present disclosure advantageously does not need to modifythe existing web browser environment 103. That is, in an embodiment, thepresent disclosure does not change the way that the browser 103interacts with local system 104 through existing web standards (e.g.,HTTP, XML, RESTful services, etc.). Thus, the present disclosureovercomes the “sandboxing” problem—where the browser defines thelocal-machine API surface that web-based applications may utilize,forcing device developers to modify the browser should they wish toprovide web applications access to additional hardware/software moduleson local device 104. More specifically, the sandboxing problem isovercome, in an embodiment, by leaving the browser intact and insteadconfiguring modules 105, 115 to provide an interface to local system 104or remote server 114, respectively, to expose the (additional)functionality of local hardware 111/software 112 to the web-browserbased application 102.

In one embodiment, process 200 in FIG. 2 provides access to local system104 via a representational state transfer (REST) API set.

Referring to FIG. 3, a flowchart illustrating an exemplary process forfacilitating web-based interaction with a local system, according to anembodiment of the present disclosure, is shown. More specifically,process 300 illustrates an example method of taking a picture with a webcamera located within local hardware 111, according to the presentdisclosure.

In step 302, in response to a user input 101 accepted at web client 102within web browser environment 103, a picture is saved to a web-basedservice. In an embodiment, in addition to communicating with localsystem 104, the user may also access a remote server 114. In anembodiment, remote server 114 is a computing device comprised of aprivate server, accessible by only user 110. In one embodiment, remoteserver 114 is a computing device comprised of one or more public servershosting public, web-based services such as media sharing sites (e.g.,FLICKR®), social media services (e.g., FACEBOOK®), remote data back-upservices (e.g., DROPBOX®), and location-based services (e.g.,FOURSQUARE®).

In step 304, web client 102 communicates with local system 104 inresponse to user input 101 by causing local system interface 105 togenerate and transmit a request signal 106 to local web server 107.

In step 306, in response to user input 101 of user 110, local web server107 receives a request signal 106 from local system interface 105, andthereby causes the web camera—located at local hardware 111 of localsystem 104—to take a picture. This information is collected at local webserver 107 and response signal 109—containing the information—is sentback to web client 102. In an embodiment, the only information sent backto web client 102 is the picture taken by the web camera. In anembodiment, additional information concerning completion of operation(s)is contained in response signal 109. In yet another embodiment, only aportion of the picture is returned to web client 102 in response signal109. Similarly, for embodiments where a requested action does notinvolve taking a picture, (e.g., determining a location of local system104, reading and/or writing a file, and/or utilizing local hardware 111output devices) response signal 109 contains all, some, none, or aportion of information accessed and/or generated at local system 104.

In step 308, web client 102 determines, based on user input 101, whetherit needs to communicate with remote server 114—remotely located from webbrowser environment 103—to save the picture to remote server 114 of aweb-based service. If it is not necessary for web client 102 tocommunicate with remote server 114, an output signal is sent to webclient 102 indicating to user 110 that the requested action—specified byuser input 101—has been completed in step 316. Otherwise, in step 310,response signal 109 is transmitted from local system interface 105 toremote server interface 115. That is, local system interface 105 moduletransmits at least a portion of response signal 109 containing thepicture to remote server interface 115.

In response, remote server interface 115 sends a signal containing thepicture to remote server 114 in step 312. In an embodiment, remoteserver interface 115 provides additional APIs that facilitateinteraction with remote server 114; without requiring additionaldeveloper knowledge of the configuration of remote server 114. In anembodiment, this is accomplished by providing additional APIs forweb-based development models (i.e., HTML, HTML5, CSS, RESTS, JavaScript,etc.). After the picture has been saved to remote server 114 of aweb-based service, web client 102 notifies user 110 that the requestedaction has been completed in step 314.

Referring to FIGS. 4A-B and 5A-B, flowcharts illustrating exemplaryprocesses for facilitating single-step and multi-step security methods,according to embodiments of the present disclosure, are shown. That is,processes 400, 410, 500 and 510 relate to security measures forpreventing unauthorized access to local system 104. In an embodiment,access is restricted to local system 104 via APIs providing access to alimited set of local hardware 111 and local software 112. In anembodiment, web client 102 determines whether the action requested byuser input 101 will generate an authorized request signal 106. In anembodiment, web client 102 determines whether the action requested byuser input 101 is recognized by local system interface 105. If requestsignal 106 is not an authorized signal, web client 102 will not permitrequested action.

The requested action may be authorized either in a single step as inprocess 400, or in multiple steps as in process 410. Where single-stepsecurity process 400 is utilized, a determination is made in step 402 asto whether permission has been granted to web client 102 to access localhardware 111 and/or local software 112. In alternate embodiments,permission may be granted by an administrator of a system containing webclient 102, local system 104, and/or an operating system associated withany such computing devices. Permission may also be granted at an APIlevel (e.g., oAuth or authentication using a well-known token, such asAPI-Key and Permission Flags, etc.). In an alternate embodiment,permissions may be determined and granted by web client 102 based upondigital signatures by the developer, which verifies web client 102 issafe to interact with certain classes of local systems 104.

In single-step security process 400, if permission is granted for webclient 102 to access local hardware 111 and/or local software 112, localweb server 107 allows access to local hardware 111 and/or local software112 in step 404. If web client 102 does not have permission, local webserver 107 denies access to local hardware 111 and/or local software 112in step 406. In an embodiment, web client 102 may be configured todisplay a permission status to user 110 via a GUI.

In multi-step security process 410, permission is provided to the userat multiple stages and/or access credentials are checked at multiplestages of communication between web client 102 and local system 104.When at least two steps are utilized to ensure security of local system104 is not compromised, it is first determined whether web client 102has permission to access local system 104 in step 412. If permission isnot granted, local web server 107 denies access to local hardware 111and/or local software 112 in step 418. Where permission is granted forweb client 102 to access local hardware 111 and/or local software 112,local web server 107 allows access to local hardware 111 and/or localsoftware 112 in step 414. Access credentials are then provided to localweb server 107 in step 416, thereby allowing local web server 107 toaccess local hardware 111 and/or local software 112 in step 420. In suchan embodiment, the two-level authentication process is employed asfollows: A first authentication level preferably includes web client102, wherein web client 102 files (e.g., OPC, CAB, ZIP, or EXE) aredigitally signed by the developer to verify that the application is safeto run; and a second authentication level occurs at an API level (e.g.,oAuth or authentication using a well-known token such as an API-Key orPermission Flags).

Referring to FIGS. 5A-B, authentication may be handled at least in parton a per-device-basis and/or a per-application-basis, respectively.Per-device-based security process 500 allows or denies access tospecific devices in local hardware 111. For example, authenticationprocess 500 may occur at local web server 107 which then determines atstep 502 if web client 102 may access a web camera (i.e., a localhardware 111) on local system 104. In step 504, access to the web camerain local hardware 111 is allowed only if permission has been granted.Otherwise, in step 506, permission is denied. In alternate embodiments,permission is granted to access: only one device in local hardware 111;only specific devices in local hardware 111; and/or only specificdevices by a limited set of web clients 102.

In an embodiment, per-application-based security process 510 operates ina similar fashion to per-device-based security process 500. However,per-application-based security process 510 allows or denies access tospecific applications and/or services in local software 112. Forexample, process 510 may determine if local web server 107 is allowedaccess to calendar application residing in local software 112 in step512. If so, process 510 proceeds to step 514; otherwise process 510proceeds to step 516. In alternate embodiments, permission is granted toaccess: only one application in local software 112; only specificapplication(s), while other specific applications (e.g., operatingsystem kernel) are excluded; and/or specific applications by a limitedset of web clients 102.

Various embodiments of the present disclosure utilize some or all of theabove-described security processes. When determining whether web client102 has permission to perform a specific task, an embodiment may verifywhether local web server 107, in response to receiving request signal106, is authorized to communicate with local hardware 111 and/or localsoftware 112.

Referring now to FIG. 6, a flowchart illustrating an exemplary process600 for facilitating web-based interaction with a local system,according to an embodiment of the present disclosure, is shown. Inprocess 600, steps 602-606 are executed in a similar fashion to steps202-206 described above, respectively. Then, in step 608, process 600determines whether web client 102 desires to communicate with remoteserver 114, which may be remotely located from web browser environment103. If step 608 is positive, local system interface 105 transmitsresponse signal 109—from local web server 107—to remote server interface115, and remote server interface 115 sends at least a portion ofresponse signal 109 to remote server 114, as shown in step 610.Otherwise, in step 612, an output signal is sent to wet; client 102indicating to user 110 that the requested action—specified by user input101—has been completed.

Referring now to FIG. 8, a block diagram illustrating aninterrelationship between exemplary components that facilitate web-basedinteraction with a local system, according to an embodiment of thepresent disclosure, is shown. Configuration 800 illustrates it is notnecessary for all components of the present disclosure to reside at thesame location. That is, in the embodiment of configuration 800, remoteserver 114 is at “location 3” 813 (e.g., a server room in California).User input 101 is entered at web client 102 residing within web browserenvironment 103 at “location 1” 811 (e.g., a laptop computer in a coffeeshop in New York City). Local system 104 is at “location 2” 812 (e.g., acomputing device in Texas). In other exemplary embodiments, some or allof “location 1” 811, “location 2” 812, and “location 3” 813 may residewithin a single address.

Referring to FIG. 9, a block diagram illustrating an interrelationshipbetween exemplary components that facilitate web-based interaction witha local system, according to an embodiment of the present disclosure, isshown. That is, configuration 900 includes specific commands that accesslocal system 104. In an embodiment, JavaScript developers useXMLHttpRequest to local API service 903 for making calls to local webserver 107. This allows web client (i.e., HTML/CSS/JavaScript-basedapplication 901) to access local device services (e.g., WriteFile topersist content from the running application, a camera API to capture animage from an on-device camera, GPS/Location Framework to obtain acurrent location, etc.). In such an embodiment, XMLHttpRequest to remoteweb service 902 and the URL http://localhost/services/camera/capture areused to obtain a photo from a web camera on local system 104. To uploada captured picture to a cloud hosted web service 906 (e.g., the FLICKR®service from Yahoo! Inc. of Sunnyvale, Calif.), the XMLHttpRequest toremote web service 902 uses URL http://api.flickr.com/services/upload/.In alternate embodiments, other operating system APIs 904 and devicedrivers 905 may be accessed and utilized in a similar manner asdescribed herein above.

Referring now to FIG. 7, a block diagram of an example computing device(or computer system) 700 that can be configured to implement variousaspects of time-managing emails, in accordance with one or moreembodiments of the present disclosure, is shown. In an embodiment,computing device 700 implements local system 104 (or any other componentof configuration 100).

Computing device 700 includes one or more processors or processing units702, one or more computer readable media 704 which can include one ormore memory and/or storage components 706, one or more input/output(I/O) devices 708, and a bus 710 that allows the various components anddevices to communicate with one another. Computer readable media 704and/or one or more I/O devices 708—can be included as part of, oralternatively may be coupled to, computing device 700. Bus 710represents one or more of several types of bus structures, including amemory bus or memory controller, a peripheral bus, an acceleratedgraphics port, a processor or local bus, and so forth, using a varietyof different bus architectures. Bus 710 may include wired and/orwireless buses.

Memory/storage component 706 represents one or more computer storagemedia. Memory and/or storage 706 may include volatile media (such asrandom access memory (RAM)) and/or nonvolatile media (such as read onlymemory (ROM), Flash memory, optical disks, magnetic disks, and soforth). Memory and/or storage 706 may include fixed media (e.g., RAM,ROM, a fixed hard drive, etc.) as well as removable media (e.g., a Flashmemory drive, a removable hard drive, an optical disk, etc.).

The techniques discussed herein may be implemented in software, withinstructions executed by one or more processing units 702. It is to beappreciated that different instructions can be stored in differentcomponents of computing device 700, such as in a processing unit 702, invarious cache memories of a processing unit 702, in other cache memoriesof device 700 (not shown), on other computer readable media, and soforth. Additionally, it is to be appreciated that the location whereinstructions are stored in computing device 700 may change over time.

One or more I/O devices 708 allow a user to enter commands andinformation to computing device 700, and also allow information to bepresented to the user and/or other components or devices. Examples ofinput devices include a keyboard, a cursor control device (e.g., amouse), a microphone, a scanner, and so forth. Examples of outputdevices include a display device (e.g., a monitor or projector),speakers, a printer, a network card, and so forth.

Various techniques may be described herein in the general context ofsoftware or program modules. Generally, software includes routines,programs, objects, components, data structures, and so forth thatperform particular tasks or implement particular abstract data types. Animplementation of these modules and techniques may be stored on ortransmitted across some form of computer readable media. Computerreadable media may be any available medium or media that can be accessedby a computing device. By way of example, and not limitation, computerreadable media may comprise “computer storage media” and “communicationsmedia.”

“Computer storage media” include volatile and non-volatile, andremovable and non-removable media implemented in any method ortechnology for storage of information such as computer readableinstructions, data structures, program modules, or other data. Computerstorage media include, but are not limited to, RAM, ROM, EEPROM, Flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical storage, magnetic cassettes, magnetic tape, magneticdisk storage or other magnetic storage devices, and/or any other mediumwhich can be used to store the desired information and which can beaccessed by a computer.

“Communication media” typically embody computer readable instructions,data structures, program modules, or other data in a modulated datasignal such as carrier wave or other transport mechanism. Communicationmedia may also include any information delivery media. The term“modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example and not limitation, communication mediainclude wired media, such as a wired network or direct-wired connection,and wireless media, such as acoustic, RF, infrared, and other wirelessmedia. Combinations of any of the above are also included within thescope of computer readable media.

Generally, any of the functions or techniques described herein can beimplemented using software, firmware, hardware (e.g., fixed logiccircuitry, system on a chip), manual processing, or a combination ofthese implementations. The terms “module” and “component” as used hereingenerally represent software, firmware, hardware, or combinationsthereof. In the case of a software implementation, the module orcomponent represents program code that performs specified tasks whenexecuted on a processor (e.g., CPU or CPUs). The program code may bestored in one or more computer readable memory devices. The features ofthe present disclosure described herein are platform-independent,meaning that the techniques may be implemented on a variety ofcommercial computing platforms having a variety of processors.

As will be apparent to one skilled in the relevant art(s) after readingthe description herein, computing device 700 may be configured as anynumber of computing devices such as a game console, a portable mediaplayer, a desktop, a laptop, a server, a notebook computer, a tabletcomputer, a PDA, a mobile computer, a smart telephone, a mobiletelephone, an intelligent communications device or the like.

While various aspects of the present disclosure have been describedabove, it should be understood that they have been presented by way ofexample and not limitation. It will be apparent to persons skilled inthe relevant art(s) that various changes in form and detail can be madetherein without departing from the spirit and scope of the presentdisclosure. Thus, the present disclosure should not be limited by any ofthe above described exemplary aspects, but should be defined only inaccordance with the following claims and their equivalents.

In addition, it should be understood that the figures in theattachments, which highlight the structure, methodology, functionality,and advantages of the present disclosure, are presented for examplepurposes only. The present disclosure is sufficiently flexible andconfigurable, such that it may be implemented in ways other than thatshown in the accompanying figures.

Further, the purpose of the foregoing Abstract is to enable the U.S.Patent and Trademark Office and the public generally and especially thescientists, engineers and practitioners in the relevant art(s) who arenot familiar with patent or legal terms or phraseology, to determinequickly from a cursory inspection the nature and essence of thistechnical disclosure. The Abstract is not intended to be limiting as tothe scope of the present disclosure in any way.

1. A method for facilitating web-based interaction with a local system,the method executing on at least one processor of a computing device,comprising the steps of: (a) detecting an input, within a user interfacescreen of an application executing on the computing device, at a webclient located within a web browser environment; (b) communicating withthe local system, in response to receiving the input, by causing a localsystem interface, located at the web browser environment, to generateand transmit a request signal to a local web server, located at, andoperated by, the local system; and (c) receiving from the local webserver, in response to transmitting the request signal, a responsesignal containing information collected from one of a local hardware anda local software, located at, and operated by, the local system.
 2. Themethod of claim 1, wherein step (a) comprises the step of: verifyingwhether the request signal is an authorized signal recognized by thelocal system interface.
 3. The method of claim 1, wherein step (c)comprises the step of: verifying whether the local web server, inresponse to receiving the request signal, is authorized to communicatewith one of the local hardware and local software.
 4. (canceled) 5.(canceled)
 6. The method of claim 1, further comprising the step of: (d)determining whether the web client desires to communicate with a remoteserver remotely located from web browser environment.
 7. The method ofclaim 6, further comprising the steps of: when the determining step (d)is positive: (e) causing the local system interface to transmit theresponse signal to a remote server interface located within the webbrowser environment; and (f) causing the remote server interface to sendthe response signal, from the web client, to the remote server; and whenthe determining step (d) is negative: (g) sending the response signal tothe web client.
 8. One or more computer storage media having storedthereon multiple instructions that implement web-based interaction witha local system component by, when executed by one or more processors ofa computing device, causing the one or more processors to: (a) detect aninput, within a user interface screen of an application executing on thecomputing device, at a web client located within a web browserenvironment; (b) communicate with the local system, in response toreceiving the input, by causing a local system interface, located at theweb browser environment, to generate and transmit a request signal to alocal web server, located at, and operated by, the local system; and (c)receive from the local web server, in response to transmitting therequest signal, a response signal containing information collected fromone of a local hardware and a local software, located at, and operatedby, the local system.
 9. One or more computer storage media as recitedin claim 8, wherein the multiple instructions further cause the one ormore processors to verify whether the request signal is an authorizedsignal recognized by the local system interface.
 10. One or morecomputer storage media as recited in claim 8, wherein the multipleinstructions further cause the one or more processors to verify whetherthe local web server, in response to receiving the request signal, isauthorized to communicate with one of the local hardware and localsoftware.
 11. One or more computer storage media as recited in claim 8,wherein the local hardware is one of: a camera; a scanner; a GPSantenna; a sensor; and a motor.
 12. One or more computer storage mediaas recited in claim 8, wherein the web browser environment is located ona computing device chosen from the group consisting of: a desktopcomputer; a mobile computer; a server; a tablet computer a PDA; and amobile telephone.
 13. One or more computer storage media as recited inclaim 8, wherein the multiple instructions further cause the one or moreprocessors to: (d) determine whether the web client desires tocommunicate with a remote server remotely located from web browserenvironment.
 14. One or more computer storage media as recited in claim13, wherein the multiple instructions further cause the one or moreprocessors to: when the determination in (d) positive: (e) cause thelocal system interface to transmit the response signal to a remoteserver interface located within the web browser environment; and (f)cause the remote server interface to send the response signal, from theweb client, to the remote server; and when the determination in (d) isnegative: (g) send the response signal to the web client.
 15. Acomputing device for facilitating web-based interaction with a localsystem, comprising: (a) means for detecting an input, within a userinterface screen of an application executing on the computing device, ata web client located within a web browser environment; (b) means forcommunicating with the local system, in response to receiving the input,by causing a local system interface, located at the web browserenvironment, to generate and transmit a request signal to a local webserver, located at, and operated by, the local system; and (c) means forreceiving from the local web server, in response to transmitting therequest signal, a response signal containing information collected fromone of a local hardware and a local software, located at, and operatedby, the local system.
 16. The computing device of claim 15, furthercomprising: (d) means for verifying whether the request signal is anauthorized signal recognized by the local system interface.
 17. Thecomputing device of claim 15, further comprising: (e) means forverifying whether the local web server, in response to receiving therequest signal, is authorized to communicate with one of the localhardware and local software.
 18. (canceled)
 19. (canceled)
 20. Thecomputing device of claim 15, further comprising: (f) means fordetermining whether the web client desires to communicate with a remoteserver remotely located from web browser environment.
 21. The method ofclaim 1, further comprising the step of: (d) presenting, to the userinterface screen, an output based upon the input and at least a portionof the information contained in the response signal; wherein theapplication executing on the computing device is a web-based service.22. The method of claim 1, wherein the local system interface is anapplication programming interface (API) located within the web clientwhich facilitates communications between the application and the localsystem.
 23. The method of claim 7, further comprising the step of, whenthe determining step (d) is positive: (h) receiving from the remoteserver, in response to transmitting the response signal, a secondresponse signal containing information collected from one of a remotehardware and a remote software, located at, and operated by, the remoteserver.
 24. The computing device of claim 15, wherein the local systeminterface is an application programming interface (API) located withinthe web client which facilitates communications between the applicationand the local system.